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I.  INTRODUCTION  AND  SUMMARY 


During  the  period  covered  by  this  report,  December  1975  through  February 
1976,  Culler/Harrison,  Inc.  has  begun  the  development  of  an  experimental  real 
time  voice  conferencing  system  on  the  ARPANET.  This  conferencing  system  is  a 
continuation  of  our  previous  work  and  uses  linear  predictive  coding  (LPC)  to 
achieve  effective  data  rates  as  low  as  1000  bits  per  second  for  digital  trans- 
mission of  speech  information.  The  development  of  this  conference  system  is  a 
joint  effort  with  other  ARPA  contractors,  principally  MIT  Lincoln  Laboratories 
and  USC  Information  Sciences  Institute.  The  objectives  of  our  participation 
in  this  development  are  to  establish  a voice  conferencing  facility  on  the  ARPA- 
NET and  to  use  this  experimental  facility  to  develop  improved  procedures  for 
transmitting  and  receiving  packet  speech  drta  in  a conference  environment. 

The  Culler/Harrison  implementation  of  voice  conferencing  makes  use  of  the 
CHI  Signal  Processing  system  developed  under  ARPA  support.  Within  the  struc- 
ture of  the  protocols  for  communication  and  control  between  host  sites  developed 
for  network  voice  conferencing  [3],  we  are  implementing  a system  supporting  one 
LPC  vocoder  to  translate  between  digitally  sampled  speech  and  the  parameters 
used  for  digital  transmission  on  the  ARPANET.  This  system  will  support  up  to 
four  local  participants  in  a single  conference  sharing  the  vocoder  with  appro- 
priate switching  of  audio  signals  between  the  participants.  Current  plans 
provide  for  up  to  six  other  sites  and  sixteen  nonlocal  participants.  Conference 
conversation  is  from  one  speaker  to  all  other  participants,  with  speaker  selec- 
tion and  conference  participation  determined  by  a conference  chairman  located 
at  one  site.  The  introduction  to  Chapter  III  gives  further  details  of  the  con- 
ference organization. 

The  majority  of  our  efforts  up  to  this  point  have  been  in  preliminary 
planning  and  implementation  of  the  initial  version  of  the  network  voice  con- 
ferencing system.  This  system  is  an  extension  of  the  network  voice  system 
which  provided  continuous  voice  communication  between  two  speakers  using  LPC 
for  speech  compression.  The  extension  provides  a set  of  control  messages  for 
selecting  the  speaker  and  data  message  transmission  and  receiving  programs 
which  can  dynamically  respond  to  this  control.  A separate  chairman  program  has 
also  been  developed  to  provide  the  control  for  a network  conference.  Both  chair- 
man and  local  conference  control  program  provide  for  monitoring  of  significant 
events  and  recording  of  the  data  gathered  for  subsequent  evaluation.  This 
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information  provides  a record  of  some  aspects  of  system  performance  and  serves 
to  aid  in  the  development  of  improved  protocols.  The  network  voice  conference 
system  is  described  in  Chapter  III.  Chapter  IV  describes  the  monitor  proce- 
dures used  and  gives  some  examples  of  the  use  of  the  trace  record. 

Several  experiments  with  network  voice  conferencing  have  already  been 
completed.  These  experiments  have  involved  from  one  to  four  sites  and  up  to 
six  participants.  A demonstration  of  this  preliminary  network  voice  conference 
system  was  given  in  late  January  at  Lincoln  Labs  with  CHI,  ISI  and  Stanford 
Research  Institute  participating.  These  experiments  have  demonstrated  that 
such  a conference  system  can  function.  Much  additional  development  and  experi- 
mentation are  needed  before  it  becomes  an  operational  capability,  particularly 
if  large  numbers  of  sites  are  to  be  involved. 

During  the  next  quarter  we  expect  to  conduct  several  more  experiments  in 
an  attempt  to  increase  the  reliability  and  ease  of  use  of  the  conference  system. 
Audio  switching  equipment  will  be  integrated  to  facilitate  multiple  local 
participants.  Revised  protocols  for  coding  and  transmission  of  the  LPC  speech 
parameters  have  now  been  specified  and  should  permit  reduction  in  the  effective 
bit  rate  well  below  1000  bps.  Implementation  of  these  new  protocols  should 
commence  during  this  next  quarter. 

The  development  of  a network  voice  conferencing  system  appears  to  be  pro- 
ceeding quite  well,  and  we  believe  that  there  should  be  no  difficulty  in 
providing  a usable  facility  by  the  end  of  this  contract  period.  We  hope  that 
it  will  be  possible  to  extend  the  conference  capability  to  additional  sites  on 
the  ARPANET,  and  plan  to  explore  procedures  for  dealing  with  data  routing  pro- 
blems in  large  conferences. 
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II.  THE  CULLER/HARRISON  SIGNAL  PROCESSING  SYSTEM  j 

The  CHI  signal  processing  system  used  for  real  time,  linear  predictive 
coding  has  been  described  in  detail  in  an  earlier  technical  report  [1].  Since 
that  report  was  prepared,  one  significant  modification  in  the  hardware  con- 
figuration has  taken  place.  The  analog-to-digital  and  digital-to-analog 
conversions  are  now  performed  using  the  multi-channel  audio  signal  system 

developed  at  CHI  and  described  in  che  same  technical  report.  !* 

The  new  audio  signal  system  provides  better  sampling  time  resolution  /. 

through  an  automatic  counter  capable  of  250  nanosecond  resolution.  The  former 
system  required  software  updating  of  the  timer  after  each  sample  period  and 
had  a resolution  and  repeatability  of  one  microsecond.  The  new  system  is  inter- 
faced directly  to  the  MP-32A  processor  which  is  used  for  all  control  functions 
and  data  buffering  during  the  processing.  This  shortens  the  times  from  data 
input  to  analysis  and  from  synthesis  to  data  output.  It  places  an  additional 
load  on  the  MP-32A  processor,  however,  as  the  processor  must  service  the  analog  i 

system  for  each  point  input  and  output. 

Almost  all  processing  in  the  system  is  now  performed  in  two  processors. 

The  MP-32A  is  the  master  computer,  and  in  addition  to  the  analog  conversion 
service,  it  provides  all  input/output  functions,  data  and  message  buffering, 
parameter  formatting  for  analysis  and  synthesis  and  scheduling  of  the  other 
processor.  In  addition,  all  nonvocoder  functi  'ns  of  the  network  voice  con- 
ference system  are  performed  by  this  machine.  The  AP-90  is  a high-speed  filled 
and  floating  point  arithmetic  unit  which  performs  the  actual  analysis  and 
synthesis  computation.  It  communicates  only  with  the  MP-32A.  Network  messages 
pass  through  an  additional  processor  which  provides  the  support  for  most  IMP/ 

HOST  protocols,  including  the  reliable  transmission  protocol  for  the  very  dis- 
tant host  interface  to  the  ARPANET. 
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III.  NETWORK  VOICE  CONFERENCING 


Previous  work  has  demonstrated  successful  low  bit  rate  digital  voice  com- 
munication between  two  participants  over  the  ARPANET.  These  experiments 
utilized  a full  duplex  communication  path,  with  the  output  of  each  participant's 
analyzer  connected  logically  to  the  other's  synthesizer  inputs.  For  conferences 
with  three  or  more  participants,  it  is  not  desirable  for  everyone  to  talk  at 
once,  and  each  participant  can  only  synthesize  one  speaker's  parameters  at  a 
time.  Ar.  extension  of  the  protocols  used  for  previous  network  voice  communica- 
tion [2]  has  been  adopted  for  network  voice  conferencing.  This  protocol  is 
known  as  the  Network  Voice  Conference  Protocol  (NVCP)  [3]. 

The  conference  environment  is  essentially  half  duplex.  Only  one  person 
is  transmitting.  All  others  receive  his  messages  and  synthesize  speech  from 
them.  Therefore,  continuing  control  procedures  are  required  to  allow  for 
switching  from  one  speaker  to  the  next.  In  addition,  since  it  is  now  possible 
for  participants  to  join  and  leave  an  ongoing  conference,  the  set  of  hosts 
receiving  data  may  change.  Hence,  an  expanded  set  of  control  procedures,  with 
control  communication  between  hosts,  is  needed.  These  control  procedures  are 
implemented  as  a conference  chairman  (CHAIR),  located  at  one  host,  together 
with  local  conference  controllers  (LCC)  at  each  host  participating  in  the  con- 
ference. Both  the  CHAIR  and  LCC  are  programs  which  may  accept  input  from  human 
participants  to  help  control  their  functions.  The  LCC  may  provide  control  for 
several  participants  as  well  as  one  or  more  vocoders.  In  the  current  con- 
ference system  at  CHI  we  have  one  vocoder,  but  up  to  four  local  participants 
are  permitted  by  our  LCC. 

The  flow  of  data  oetween  participant  sites  is  directed  by  the  CHAIR,  who 
selects  which  participant  is  to  speak.  When  the  speaker  is  to  change,  three 
types  of  control  messages  must  be  sent  by  the  CHAIR.  The  first  requests  the 
old  speaker  (and  his  LCC)  to  stop  speaking  and  sending  data  messages.  The 
second  control  message  is  sent  to  all  participant  LCCs  to  identify  the  new 
speaker  whose  data  they  should  accept.  The  third  is  sent  to  the  speaker  and 
his  LCC  to  inform  him  that  he  may  speak  and  to  provide  tie  list  of  hosts  who 
should  be  sent  copies  of  the  speech  data. 

With  these  three  control  messages,  the  chairman  can  dynamically  recon- 
figure the  data  transmission  paths  to  allow  any  participant  to  speak  to  all 
others  in  the  conference.  The  utilization  of  a chairman  providing  the  control 
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than  having  all  data  sent  to  a central  location  for  distribution  to  the  lis- 
teners. It  does  require  more  time  to  change  speakers,  however,  as  control 
messages  must  reach  all  sites  before  switching  is  complete. 

The  control  messages  just  described  provide  dynamic  switching  of  the 
data  paths  in  an  established  conference.  To  establish  a conference,  and  to 
allow  participants  to  join  or  leave  an  ongoing  conference,  additional  control 
communication  is  required.  Also,  each  host  system  involved  in  the  conference 
must  agree  on  the  vocoder  and  message  transmission  parameters  to  be  used. 

Since  more  than  one  participant  may  be  located  at  a single  host  system,  parti- 
cipant negotiation  is  separated  from  system  parameter  negotiation. 

The  system  parameter  negotiation  is  identical  to  that  used  in  the  network 
voice  protocol.  It  is  started  automatically  when  the  first  "request  to  join  a 
conference"  message  is  received  by  the  CHAIR  from  a given  LCC.  This  negotiation 
establishes  the  vocoding  and  data  transmission  parameters  to  be  used  during 
the  conference.  Since  negotiation  is  carried  out  separately  with  each  host's 
LCC  by  the  conference  chairman,  while  data  transmission  takes  place  directly 
between  all  pairs  of  hosts,  the  parameters  are  in  fact  dictated  by  the  chairman. 

A separate  negotiation  procedure  is  followed  for  each  participant  which 
wishes  to  join  a conference.  This  negotiation  is  limited  at  present  to  a 
request  to  join  message  identifying  the  participant  to  the  chairman  and  an 
acceptance  or  rejection  message  returned  by  the  chairman.  The  same  rejection 
message  may  be  used  at  any  time  by  the  chairman  to  remove  a participant  from 
the  conference.  The  LCC  provides  the  actual  access  control  for  the  participants 
under  the  direction  of  the  CHAIR. 

Participants  can  communicate  directly  with  the  CHAIR,  and  vice  versa, 
through  control  messages  containing  function  codes.  The  primary  use  of  these 
is  to  permit  a participant  to  request  a turn  speaking  or  to  enable  the  speaker 
to  inform  the  CHAIR  that  he  is  through.  These  permit  an  automatic  CHAIR  pro- 
gram to  have  the  information  needed  to  schedule  speakers  on  demand. 

The  control  messages  described  up  to  this  point,  together  with  protocols 
for  when  they  must  be  used,  define  the  interface  between  hosts  participating 
in  a network  voice  conference.  A list  of  the  control  messages  uefined  at  this 
time  for  network  voice  conferencing  is  given  in  Appendix  A.  The  rest  of  this 
chapter  will  describe  the  implementation  of  the  network  voice  conferencing 
system  at  CHI,  including  tiie  interlace  between  the  system  and  participant  users. 
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This  system  has  several  components  in  addition  to  the  LPC  vocoder.  The  local 
conference  controller  (LCC)  must  interact  with  the  conference  chairman  through 
control  messages  over  the  network,  control  the  transmitter  and  receiver  for 
speech  data,  and  interact  with  the  user  through  voice  and  nonvoice  means.  The 
conference  chairman  (CHAIR)  is  used  only  when  the  conference  is  being  chaired 
locally  and  operates  separately  from  the  LCC.  It  must  also  interact  with  a 
local  user  if  manual  chairman  functions  are  being  used.  Finally,  the  system 
monitoring  facilities,  when  enabled,  collect  data  about  events  in  the  system 
for  subsequent  analysis. 


A.  The  Local  Conference  Controller 


The  network  voice  system,  which  serves  as  the  base  on  which  the  voice  con- 
ferencing system  is  being  developed,  already  provides  for  preparation  of  data 
messages  from  the  parameters  output  by  the  LPC  analysis  and  for  the  selection 
and  decoding  of  input  messages  to  obtain  the  parameters  for  LPC  synthesis. 

These  procedures,  as  well  as  the  LPC  analysis  and  synthesis,  remain  essentially 
unchanged  in  the  conferencing  system.  With  the  exception  of  the  selection  of 
input  messages  for  processing,  these  parts  of  the  system  were  described  in  a 
previous  technical  report  [1],  The  input  message  selection  will  be  described 
here. 


1.  Input  Message  Selection 

As  input  messages  are  received,  they  are  ordered  by  their  time  stamp, 
which  represents  the  time  at  the  transmitter  when  the  first  data  in  the  message 
was  processed.  Since  the  time  which  a message  takes  to  travel  from  its  source 
to  the  receiver  varies,  a delay  is  introduced  after  the  expected  time  for  a 
message's  arrival  before  it  is  used  for  synthesis.  This  delay  defines  the 
amount  by  which  a message  can  be  late  without  creating  a gap  in  the  synthesized 
output.  The  delay  is  measured  from  the  expected  arrival  time,  rather  than  the 
actual  arrival  time  of  any  particular  message,  such  as  the  first  message  after 
a silence,  to  minimize  raggedness  in  the  speech  due  to  variations  in  the  arrival 
time  of  any  particular  message.  The  establishment  of  a preferred  time  for  pro- 
cessing of  a particular  message  based  on  its  time  stamp  allows  continuation  of 
synthesis  at  the  proper  time  even  when  intervening  messages  are  lost  or  very 
late . 
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The  expected  arrival  time  for  a message  is  calculated  by  adding  the 
expected  network  transit  time  to  the  time  stamp  of  the  message.  The  expected 
network  transit  time  is  updated  each  time  a message  is  selected  for  processing 
by  the  exponential  averaging  formula: 


NT’  = NT+  fr-COT-NT) 
lb 


where  OT  is  the  observed  network  transit  time. 


OT  = Time  Received  - Time  Sent 


•-i 

r" 


and  the  time  the  message  was  sent  is  assumed  to  be  given  by  the  message  time 
stamp  plus  the  time  represented  by  the  speech  parcels  in  the  message.  A mes- 
sage is  selected  for  processing  by  the  synthesizer  when 

Time  = Time  Stamp  + NT  + D 

where  D is  the  delay  parameter  chosen  to  account  for  variations  in  the  message 
length  and  short  term  variacions  in  the  actual  network  time.  The  expected 
network  transit  time,  NX,  incorporates  the  difference  between  the  clock  used 
by  the  sender  to  generate  the  time  stamp  and  the  receiver's  clock.  This  per- 
mits NT  to  adjust  for  any  variations  in  the  clock  frequency  between  hosts. 

For  the  conference  system  the  expected  network  transit  time  from  each 
other  host  in  the  conference  will  be  different.  This  separation  could  be  main- 
tained by  saving  the  current  NT  value  for  the  old  speaker's  host  and  using  the 
value  for  the  new  speaker's  host  each  time  speakers  are  switched.  However,  if 
much  time,  has  passed  since  any  data  was  received  from  the  new  host,  the  value 
for  NT  may  no  longer  be  usable.  Instead,  we  reset  the  NT  computation  to  its 
initial  state  each  time  a speaker  switch  occurs  and  any  time  that  the  observed 
transit  time  OT  is  much  less  than  NT.  In  this  state,  NT  is  set  to  OT  for  the 
first  message  received.  Although  we  presently  keep  D fixed  when  speaker 
switching  occurs,  it  is  possible  to  maintain  different  values  for  each  host, 
depending  on  factors  such  as  the  distance  to  the  host  and  the  amount  of  speech 
data  represented  by  each  message. 
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2.  Transmitter  and  Receiver  Switching 

The  voice  conference  system  differs  from  the  network  voice  system  in 
requiring  selective  enabling,  or  switching  of  data  at  both  sides  of  each  half 
of  the  vocoder.  On  the  user  side  of  the  vocoder,  the  participant  who  is  to 
speak,  if  any,  must  have  his  microphone  enabled  for  input  to  the  LPC  analysis. 
The  speaker's  loudspeaker  or  earphone  must  be  disabled  from  output  of  his  own 
delayed,  synthetic  speech.  The  earphones  of  other  local  participants  are 
enabled  only  if  they  have  been  accepted  into  the  conference.  Actual  implementa- 
tion of  microphone  and  earphone  switching  will  be  completed  during  the  next 
quarter.  On  the  network  side,  vocoder  output  can  be  sent  to  other  hosts  only 
when  a local  participant  is  speaker.  The  list  of  hosts  to  send  the  data  to  is 
set  each  time  a new  speaker  is  selected.  Input  messages  from  the  network,  on 
the  other  hand,  are  accepted  only  if  received  from  the  host  of  the  current 
speaker. 

The  LCC  provides  these  switching  and  selection  functions  as  a layer  of 
programs  around  the  LPC  vocoder.  The  LPC  analysis  program  runs  continuously, 
processing  new  input  data  every  9.6  milliseconds  and  preparing  data  messages  for 
transmission.  The  conference  system  message  transmission  program  then  decides 
whether  to  transmit  the  message  to  its  list  of  hosts  or  to  discard  it.  The  LPC 
synthesis  program  operates  whenever  messages  are  available  on  its  input  queue 
for  selection.  The  data  message  receiver  decides  whether  incoming  messages  are 
to  be  placed  on  the  queue  or  discarded. 

The  conference  system  receiver  must  discriminate  between  messages 
arriving  from  several  different  hosts,  and  even  from  one  host,  but  representing 
data  from  different  speakers.  To  sort  these  out,  all  data  messages  except 
those  from  the  current  speaker  are  discarded  immediately  when  they  arrive. 

When  a command  is  received  from  the  chairman  to  listen  to  a speaker,  any  data 
messages  from  the  previous  speaker  which  are  waiting  for  processing  are 
immediately  discarded.  This  approach  assures  that  only  one  speaker's  messages 
will  be  available  for  selection  at  any  time. 

In  the  current  network  voice  conference  protocol  the  speaker's  trans- 
mitter must  send  copies  of  each  data  message  to  all  other  hosts.  Tt.e  list  of 
hosts  who  are  to  1>  sent  data  messages  and  the  LINK  to  be  used  at  each  is 
included  in  the  "Spt,  k To"  control  message.  This  list  is  subsequently  used  by 
the  transmitter  to  generate  the  HOST/ IMP  leader  for  each  copy.  When  no  local 
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participant  is  speaking,  there  must  Le  a way  of  inhibiting  transmission  of  data 
messages.  This  is  currently  accomplished  by  use  of  a transmission  enable  flag. 
If  this  flag  is  not  set,  any  data  messages  prepared  are  discarded.  The  trans- 
mit enable  flag  is  set  by  the  LCC  approximately  154  milliseconds  after  a "Speak 
To"  message  is  received  and  cleared  immediately  when  a "Shut  Up"  message  is 
received.  If  the  flag  is  set  and  a data  message  is  ready,  the  message  leader 
is  filled  in  for  one  host  at  a time  and  the  message  is  sent  to  the  network 
interface  processor  for  transmission  to  the  IMP.  When  the  IMP  has  accepted 
this  copy,  the  next  copy  is  prepared  and  sent.  When  all  copies  of  the  message 
have  been  sent,  the  message  is  discarded. 

3.  Participant  Interaction 

Participant  input  to  the  CHAIR  is  needed  to  allow  it  to  schedule 
speakers  on  demand.  This  control  is  provided  through  the  LCC.  In  addition,  a 
user  must  be  able  to  indicate  to  the  LCC  that  he  wishes  to  join  a conference 
or  that  he  is  ready  to  leave  it.  The  LCC,  in  turn,  needs  to  inform  the  user 
that  he  has  been  accepted  into  the  conference,  that  he  has  the  floor  and  may 
speak,  or  that  he  must  stop  speaking.  This  communication  between  the  LCC  and 
the  local  participants  is  provided  by  the  use  of  two  lights  and  a 15  key  key- 
board, which  together  witli  a microphone  and  earphone  make  up  a conference 
console. 

O O 

LISTEN  SPEAK 


Figure  1 

Conference  Participant's 
Console 
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A user  indicates  that  he  wishes  to  participate  in  the  conference  by 
pushing  the  JOIN  key.  No  user  identification  is  used  at  this  time,  so  the  LCC 
sends  a "Request  to  Join"  message  to  the  CHAIR,  identifying  the  participant  by 
the  conference  console  (1-4)  where  he  is  located.  When  the  participant  is 
accepted  by  the  CHAIR,  the  LISTEN  light  is  lit  and  the  user's  earphone  is  enabled 
for  vocoder  output. 
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A participant  wishing  to  leave  the  conference  pushes  the  LEAVE  key. 

The  LCC  then  sends  a "Lost  a Participant"  message  to  the  CHAIR.  When  a 
"Remove  a Participant"  message  is  received,  the  LCC  clears  both  lights  for  the 
participant  named. 

Participant  communication  to  the  CHAIR  is  supported  through  user  func- 
tion codes  generated  by  the  keys  1 through  9.  Functions  1 and  2 are  assigned 
meanings  of  "I  want  to  talk"  and  "I've  finished  talking",  respectively.  These 
functions  are  for  the  CHAIR's  information  only,  the  LCC  does  not  attempt  to 
interpret  them. 

The  primary  communications  between  the  LCC  and  the  user  are  provided  in 

response  to  the  control  commands  "Speak  To " and  "Shut  Up"  received  by  the 

LCC  and  naming  a participant  as  the  speaker.  Tin  SPEAK  light  is  lit  and  the 
LISTEN  light  is  turned  off  to  indicate  that  the  participant  has  the  floor  when 

the  "Speak  To " message  is  received.  The  SPEAK  light  is  turned  off  and 

the  listen  light  lit  when  the  "Shut  Up"  message  is  received.  In  addition,  the 
CHAIR  to  participant  function  1,  which  is  a request  to  "Wrap  Up"  what  is  being 
said,  is  indicated  to  the  participant,  if  he  is  speaking,  by  turning  on  his 
listen  light. 

Since  the  current  conference  consoles  are  actually  general  purpose 
interactive  terminals,  there  is  also  a display  screen  (a  direct  view  storage 
tube)  available  for  additional  information  from  the  LCC.  At  present,  the  LCC 
prints  the  identification  (host  name  and  extension  number)  of  the  speaker  each 
time  a "Listen  To " message  is  received. 

In  an  attempt  to  improve  the  responsiveness  of  the  conference  system 
to  the  user,  the  LCC  also  monitors  the  response  of  the  CHAIR  during  the  con- 
ference. Every  five  seconds  an  INQ  control  message,  as  defined  by  the  network 
voice  protocol,  is  sent  to  the  host  of  the  CHAIR.  If  a READY  response  is  not 
received  withLn  ten  seconds  a message  is  displayed  for  local  participants 
warning  them  that  the  CHAIR  may  be  genu.  Similarly,  if  a IMP/HOST  message  is 
received  indicating  that  the  host  is  dead,  it  is  passed  on  to  local  participants. 
The  aim  is  to  lessen  the  feeling  of  isolation  that  can  arise  when  there  is  no 
response  to  user  requests  from  the  system. 
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B.  The  Conference  Chairman 


The  role  of  the  CHAIR  is  primarily  to  schedule  speakers  for  the  conference 
and  to  communicate  this  information  to  the  LCCs.  To  help  it  in  its  scheduling 
duties,  individual  participants  can  notify  the  CHAIR  that  they  wish  to  speak 
or  are  through  speaking. 

It  is  possible  for  the  CHAIR  to  be  implemented  entirely  as  an  automatic 
program,  much  like  the  processor  scheduler  in  a single  processor  operating 
system.  On  the  other  hand,  all  decisions  could  be  made  by  a human  chairperson, 
with  the  CHAIR  program  simply  making  the  participant  requests  known  and 
accepting  manual  control  of  each  speaker  change.  We  have  chofen  to  use  a mixed 
strategy,  with  a human  chairperson  informed  of  all  requests  and  the  actions 
taken  by  the  CHAIR  program.  Both  program  and  human  are  able  to  make  a limited 
set  of  switching  decisions. 

1.  The  CHAIR  Program 

The  speaker  selection  algorithm  used  by  the  CHAIR  program  is  first-come, 
first-served,  eased  on  user  "Request  to  Speak"  functions.  The  speaker  is 
changed  when  the  current  speaker  sends  a "Speaker  Done"  function.  The  CHAIR 
responds  by  sending  a "Shut  Up"  control  message  to  the  speaker's  LCC.  If  any 
requests  to  speak  are  outstanding,  the  oldest  one  is  select.  "Listen  To" 
messages  are  sent  to  each  active  LCC.  A "Speak  To"  message  is  prepared  listing 
each  active  host  and  this  message  is  sent  to  the  LCC  of  the  new  speaker. 

The  human  chairman  can  presently  override  the  speaker  selection  proce- 
dures in  only  two  ways.  First,  he  can  force  the  selection  of  the  next  speaker 
in  line,  which  has  the  same  effect  as  receiving  a "Speak  Done"  function  from 
the  current  speaker.  Second,  he  can  insert  a request  to  speak  from  his  own 
extension  at  the  head  of  the  queue  of  pending  requests.  These  facilities  permit 
the  human  chairman  to  reply  to  the  current  speaker,  or  to  break  off  the  current 
speaker  if  he  is  unable  or  unwilling  to  voluntarily  finish  what  he  has  to  say. 
They  do  not  permit  selection  of  an  arbitrary  participant  as  the  next  speaker, 
or  skipping  a particular  participant's  request  to  speak  (although  his  turn  can 
be  made  arbitrarily  short).  Such  facilities  are  consistent  with  the  current 
structure,  and  could  be  added  if  they  appear  to  be  necessary. 
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In  addition  to  the  speaker  selection  function,  the  CHAIR  is  also  res- 
ponsible for  negotiating  with  LCCs  about  the  vocoder  parameters  and  accepting 
or  rejecting  requests  from  LCCs  to  add  new  participants  to  the  conference. 

These  functions  are  presently  performed  entirely  by  the  CHAIR  program,  although 
at  some  future  time  it  may  be  desirable  for  the  human  chairman  to  have  some 
control  over  participation  in  the  conference.  Vocoder  parameter  negotiation  is 
initiated  when  a "Request  to  Join  the  Conference"  is  received  over  the  initial 
connection  link.  The  CHAIR  always  serves  as  negotiation  master.  The  CHAIR 
accepts  any  "Request  to  Join"  from  an  LCC  once  the  negotiation  is  completed, 
unless  the  system  limit  for  participants  (currently  20)  is  exceeded,  in  which 
case  a "Remove  a Participant"  message  is  sent  to  reject  the  new  participant. 

In  the  same  spirit,  a participant  is  removed  from  the  conference  only  in  res- 
ponse to  a "Lost  a Participant"  message  from  an  LCC.  The  CHAIR  does  not 
voluntarily  terminate  an  individual's  participation  in  the  conference. 

The  CHAIR  program  uses  two  data  structures  to  manage  information  about 
the  conference.  The  first,  UHOSTS,  has  one  four-word  entry  for  each  host  whose 
LCC  has  joined  or  is  in  the  process  of  joining  the  conference.  This  entry  con- 
tains the  HOST  ID,  the  link  to  be  used  for  sending  commands  to  the  LCC  (and, 
therefore,  the  data  link,  which  is  the  command  link  + 1),  the  state  of  the 
connection  (used  primarily  during  parameter  negotiation)  and  a save  cell  con- 
taining the  extension  of  the  user  whose  request  to  join  the  conference  triggered 
the  parameter  negotiation.  "Listen  To"  messages  are  sent  to  all  LCCs  in  the 
UHOSTS  list  who  have  completed  parameter  negotiation  each  time  a speaker  selec- 
tion takes  place. 

The  second  data  structure,  USERLS,  contains  a three-word  entry  for 
each  participant  in  the  conference.  This  entry  contains  the  Host  ID  and  exten- 
sion of  the  participant  and  a link  field  used  to  maintain  the  queue  of  pending 
requests  to  speak.  A participant  is  added  to  this  list  when  a "Request  to 
Join"  message  is  received,  if  he  is  already  present,  the  message  is  not 
acknowledged.  A participant  is  removed  when  a "Lost  a Participant"  message 
is  received.  Request  to  speak  functions  cause  the  entry  for  the  participant 
to  be  linked  to  the  end  of  the  request  queue,  unless  already  present,  in  which 
case  the  new  request  is  ignored.  When  a participant  is  selected  to  be  speaker, 
his  entry  is  removed  from  the  request  queue.  The  participant's  entry  will  also 
be  removed  from  the  request  queue  if  a "Speaker  Done"  function  is  recieved 
before  the  participant  is  selected  as  the  speaker. 
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In  order  to  allow  for  hosts  leaving  and  rejoining  the  conference,  pro- 
cedures are  included  for  removing  a host  and  all  its  users  from  the  UHOSTS  and 
USERLS  lists.  When  a participant  is  removed  from  the  USERLS  list,  he  is  also 
removed  from  the  request  to  speak  queue  and,  if  he  is  speaking,  the  next 
speaker  is  selected.  There  are  three  ways  in  which  a host  may  currently  leave 
the  conference.  The  only  normal  way  is  for  the  LCC  is  send  a termination  con- 
trol message.  A "destination  host  or  IMP  dead"  IMP/HOST  message  is  recognized 
as  an  indication  that  the  host  LCC  is  no  longer  accessible,  and  the  host  is 
removed.  Finally,  if  a "Request  to  Join"  control  message  is  received  on  the 
initial  connection  link,  it  is  assumed  that  the  host's  LCC  has  been  reini- 
tialized. In  this  last  case,  the  host  is  removed  and  immediately  reinserted 
as  the  vocoder  parameter  negotiation  begins.  The  host  entry  is  also  removed 
if  the  vocoder  negotiation  fails. 


2.  Interaction  with  the  Human  Chairman 


The  human  chairman  communicates  with  the.  CHAIR  program  through  a set 
of  keys  on  his  input  keyboard.  Output  from  the  program  to  the  chairman  is  on 
a direct  view  storage  tube.  Any  of  the  four  standard  user  consoles  connected 
to  the  CHI  system  may  be  used  as  a chairman's  station.  The  console  used  is 
the  one  where  the  Network  Voice  Conference  program  is  initiated.  The  chairman 
control  keys  are  disjoint  from  the  user  control  keys,  since  a chairman  is 
normally  also  a participant  in  the  conference.  There  are  currently  five  con- 
trol input  keys  whose  functions  are  defined,  seven  additional  keys  are 
available  in  the  same  cluster. 


CHAIR 

NEXT 

CLR 

SPKR 

LIST 

REQ 

WRAP 

UP 

LIST 

PART. 

Figure  2 


Chairman  Console 
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Pushing  the  CHAIR  NEXT  keys  causes  the  chairman,  if  he  is  a participant 
in  the  conference,  to  be  placed  at  the  head  of  the  queue  of  requests  to  speak, 
the  CLR  SFKR  input  causes  a "Shut  Up"  message  to  be  sent  to  the  current  speaker 
and  schedules  the  next  participant  in  the  request  queue.  The  WRAP  UP  input 
causes  a CHAIR  to  USER  control  message  with  the  Wrap  Up  function  code  to  be 
sent  to  the  current  speaker,  if  any.  The  remaining  input  keys  allow  the  chair- 
man to  have  listed  at  his  console  the  participants  requesting  to  speak  (LIST 
REQ)  or  all  the  participants  (LIST  PART) . The  listing  is  in  the  form  hostname- 
extension  number. 

At  present,  most  control  message  arrivals  and  speaker  selections  are 
displayed  at  the  chairman's  console.  This  provides  a running  record  of  the 
speaker  requests  and  scheduling,  as  well  as  the  arrival  and  departure  of  parti- 
cipants and  hosts. 


3.  Relationship  with  the  LCC 


The  CHAIR  program  is  entirely  independent  of  the  LCC  which  may  be  run- 
ning at  the  same  time.  The  CHAIR  does  not  require  a vocoder,  communicating 
with  all  LCCs  and  participants,  including  local  participants,  through  control 
messages  on  the  ARPANET.  Our  CHAIR  program  shares  an  input  keyboard  with  the 
LCC  if  the  chairman  is  a participant  in  the  conference.  Since  distinct  keys 
are  used  for  the  input  to  each,  there  is  no  difficulty  in  directing  the  inputs 
to  the  proper  process.  Control  input  from  the  ARPANET  is  separated  between 
LCC  and  CHAIR  through  separate  LINK  assignment  for  each,  just  as  data  is 
separated  from  control  by  LINK. 
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IV.  MONITORING  OF  NETWORK  VOICE  CONFERENCE  EXPERIMENTS 


During  network  conferencing  experiments  a record  is  made  of  events  as  they 
occur,  together  with  relevant  information  about  the  state  of  the  system  at  the 
time  the  event  occurs.  The  purpose  of  this  data  gathering  is  to  obtain  more 
information  to  judge  the  behavior  of  the  communications  network  and  the  computer 
systems  which  are  connected  through  it.  We  are  also  interested  in  evaluating 
the  effectiveness  of  the  procedures  adopted  to  deal  with  their  behavior. 

Finally,  we  want  to  detect  differences  in  implementation  of  the  voice  protocols 
which  may  affect  the  performance  of  the  conference  system. 

A.  Events  Monitored 

The  events  currently  being  monitored  include  the  sending  or  processing  of 
a control  message.,  the  transmission  of  a data  message,  the  selection  of  an 
input  message  for  processing  and  discarding  of  an  out-of-order  data  message. 

For  control  messages,  the  time  the  message  was  processed  or  created  is  recorded 
along  with  the  message  itself.  For  data  messages  both  the  time  the  message 
was  received  or  generated  and  the  time  it  was  processed,  or  the  last  copy  sent, 
are  recorded.  In  addition,  the  data  message  leader  and  header  and  the  expected 
network  transit  time  (NT)  are  saved.  Approximately  400  to  8l'0  events  are 
traced  each  minute,  with  higher  levels  of  activity  occuring  ’hen  the  CHAIR  is 
located  at  CHI. 

B.  Processing  of  Trace  Data 

The  trace  data  gathered  from  a conferencing  session  is  written  on  disk 
during  the  session  using  a file  specified  when  the  conference  system  was  loaded. 
This  file  is  normally  processed  using  the  Signal  Interactive  Mathematical  Sys- 
tem, an  array  oriented,  programmable,  interpretive  system  accessible  from  the 
CHI  user  consoles.  This  system  permits  computation  and  selection  operations  on 
the  data  files  and  can  display  graphical  or  numerical  data. 

Typically,  we  begin  processing  of  the  information  from  a session  by 
selecting  the  control  message  entries  and  printing  them.  Table  1 illustrates 
a portion  of  such  an  output.  This  listing  provides  a summary  of  the  control 
flow  in  the  conference  showing  the  speaker  switching  times.  Response  times  over 
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the  ARPANET  can  be  determined  by  measuring  tha  time  from  when  a stimulus  message 
such  as  a "Speaker  Done"  function  is  sent  and  the  response,  the  "Shut  Up"  mes- 
sage from  the  chair.  Similarly,  speaker  selection  time  can  be  measured  by 
comparing  the  time  a "Request  to  Speak"  function  is  sent  to  the  time  the  "Speak 

To " message  is  received.  The  sample  trace  of  Table  1 is  from  a network 

conference  demonstration  on  January  23.  This  conference  was  chaired  by  exten- 
sion 4 at  Lincoln  Labs  (HOSTID  = 202).  SRI  (HOSTID  = 51),  ISI  (HOSTID  = 22) 
and  CHI  (HOSTID  = 182)  also  participated.  The  first  line  of  this  trace  is  a 
"Request  to  Speak"  from  extension  1 at  CHI.  The  third  line  is  the  "Speak  To" 
message  from  LL-4  telling  CHI-1  that  he  may  speak  and  directing  the  LCC  to 
send  data  message  to  three  hosts;  SRI  with  link  241,  ISI  with  link  241  and  LL 
with  link  225.  The  difference  in  the  TIME  column  for  these  two  events  is  35 
time  units,  about  670  milliseconds.  The  following  line  (INDEX  3306)  is  a 

message  from  CHI-1  to  the  CHAIR  that  he  is  done  speaking.  The  response  of  the 

CHAIR  on  the  next  line  is  the  control  message  "Shut  Up."  The  time  for  this 
exchange  is  43  time  units  (826  milliseconds).  Five  other  cases  of  this  combina- 
tion on  the  same  page  of  the  trace  record  range  from  450  to  730  milliseconds; 
the  elapsed  time  is  about  257  seconds.  Three  other  cases  of  a "Request  to 
Speak"  from  CHI  being  granted  immediately  (i.e.,  no  one  was  speaking)  range 
from  595  to  979  milliseconds  delay  to  the  "Speak  To"  message.  These  variations 
represent  differences  in  both  the  network  performance  and  the  response  of  the 
systems  at  Lincoln  and  Culler/Harrison. 

In  addition  to  these  timing  measurements,  the  trace  of  control  messages 
sent  and  received  has  been  very  valuable  in  identifying  differences  or  errors 
in  implementations  of  the  protocols  at  the  participating  sites.  We  have  already 
used  this  means  to  discover  problems  in  our  own  implementation  during  pre- 
liminary testing  with  only  ourselves  in  the  conference.  Other  problems  that 

occurred  during  initial  experiments  with  other  sites,  including  the  conditions 
expected  for  successful  termination  of  the  vocoder  negotiations  and  transmission 
of  invalid  host  icentifiers  in  the  "Speak  To"  command,  were  found  or  verified 
using  this  information. 

The  data  message  entries  in  the  trace  record  have  been  an  important  source 
of  information  for  us  in  developing  an  implementation  of  the  input  message 
selection  procedures  described  earlier.  They  provide  evidence  of  the  variations 
which  occur  in  network  transit  times  and  make  it  possible  to  determine  directly 
the  amount  of  data  transferred  over  the  network  during  a conference.  We  expect 
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loading  to  obtain  more  data  about  the  variations  in  throughput  and  in  out-of- 
order  arrivals  of  messages. 

Table  2 is  a part  of  the  trace  from  the  same  conferencing  demonstration 
illustrated  earlier.  This  record  contains  entries  created  when  an  input  mes- 
sage was  selected  for  processing.  The  column  headed  HOST  ID  identifies  the 
entries  as  coming  first  from  Lincoln  (202)  then  ISI  (22)  and  finally  Lincoln 
for  a second  time.  The  entry  at  index  21  illustrates  a difficulty  in  the 
sender's  transmission  program.  Its  time  stamp  of  -25582  identifies  it  as 
belonging  immediately  after  the  last  message  sent  before  ISI  spoke  (index  8). 

This  message  should  have  been  sent  earlier  or  discarded  without  being  trans- 
mitted. Its  arrival  with  the  second  set  of  messages  caused  an  abnormality  in 
the  computed  network  transit  time  (NT).  If  this  new  value  of  NT  was  used  to 
time  the  selection  of  the  following  messages,  it  would  force  a long  delay  and 
exhaust  the  message  buffering  capability  of  the  receiver.  Indeed,  this  was 
precisely  what  happened  in  an  earlier  experiment.  From  examination  of  the 
trace  of  that  experiment  it  was  evident  what  the  problem  was,  and  the  input 
selection  logic  was  modified  to  reset  its  expected  time  when  the  observed  time 
was  much  shorter.  This  is  illustrated  in  the  trace  by  the  value  for  NT  in  the 
subsequent  entries  being  much  less  than  the  8969  value  computed  from  the  first 
message. 

In  general,  the  amount  of  data  gathered  from  the  data  entries  is  more 
easily  interpreted  through  graphs  of  selected  values.  Figures  3 and  4 illus- 
trate two  graphs  derived  from  the  trace  information.  Figure  3 shows  the  value 
of  NT  as  it  varies  from  speaker  to  speaker.  The  differences  in  value  between 
speakers  represent  primarily  the  different  time  frames  used  for  the  time  stamps 
in  their  messages.  The  largest  value  of  NT  was  obtained  for  ISI,  the  middle 
value  is  Lincoln,  the  lowest  value  is  SRI.  The  relative  flatness  of  each 
speaker's  segment  illustrates  the  small  variation  in  network  transit  times 
during  the  two  minutes  period  shown.  The  second  graph,  Figure  4,  illustrates 
the  short  term  variations  in  observed  transit  time  (0T)  from  the  expected  time 
(NT)  for  the  same  set  of  messages.  The  variation  rarely  exceeded  ten  time 
units  or  192  milliseconds,  and  except  for  the  messages  from  Lincoln,  was  generally 
less  than  half  that.  This  behavior  appears  to  be  better  than  often  occurs, 
particularly  at  the  time  of  day  of  this  demonstration  (1100-1200  PST). 
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The  data  gathered  here  suggests  that  a delay  (D)  of  10  to  12  time  units 
plus  the  message  length  should  be  sufficient  to  insure  that  essentially  all 
messages  will  arrive  on  u 'le.  In  fact,  a somewhat  shorter  delay  of  15  time 
units,  instead  of  the  20  called  for,  was  used.  There  were  29  messages  out  of 
over  4500  which  arrived  out  of  order  and  so  late  that  they  were  discarded. 

All  but  one  of  these  came  from  Lincoln,  which  is  over  twice  as  far  from  CHI  as 


either  of  the  other  sites  involved. 
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Table  1:  Sample  Trace  Record  — Control  Message  Entries 

YR*~»Cc.  Rc£v\i) 


ri«v 

HOST  10 

LIM< 

CC.V1AN0 

CHAIR 

WHO 

T YPZ 

— 1 *->4- 

20*70 

202 

234 

40 

2C204 

1 

101 

CHJ 

2 1 $ 

30304 

20  2 

250 

35 

20204 

13201 

cm 

J0G05 

202 

250 

37 

20204 

13201 

3 

cm 

.’.'WoOCi 

5141 

2241 

.20225 

cm 

Tr  i ' • 

v *»  nf  ' 
/O 

202 

234 

40 

20204 

1 

102 

cr.o 

*,  \ s> 

32 1 :v> 

202 

250 

•5  Cl 

20204 

1C201 

cm 

*/  wf  « A. 

3 7 235 

202 

25C 

36 

20204 

20204 

cm 

-A 

-57149 

202 

234 

40 

20204 

1 

101 

0".G 

: . > 

-32170 

2.02 

250 

*y  ^ 

20204 

13201 

cm 

V*''  . > 

-3210/ 

202 

250 

37 

20204 

IC201 

3 

cm 

■> 

-32107 

5141 

2241 

20225 

cm 

— » • i o 

-32030 

202 

250 

39 

20204 

1 

101 

cm 

-31077 

202 

234 

40 

20204 

1 

102 

CM3 

w 

-311140 

202 

250 

33 

20204 

10201 

cm 

„3 

-31039 

202 

250 

36 

20204 

20201 

cm 

57C , 

-30;,// 

202 

250 

JgO 

20204 

2200 

cm 

57:3 

-30525 

202 

254 

40 

20204 

I 

101 

<yj 

3751 

-30005 

202 

250 

OVJ 

20204 

2G2C4 

cm 

$:Z‘r 

-29102 

202 

250 

35 

20204 

1C2C1 

CMI 

5 ..'35 

-29191 

202 

250 

37 

20204 

10201 

3 

cm 

jcO 

-29191 

5141 

2241 

20225 

cm 

4139 

-2d3v<0 

202 

234 

40 

2C2C4 

1 

102 

a;o 

di-Vo 

-29322 

202 

250 

33 

20204 

10201 

am 

4147 

-2 31 05 

202 

250 

35 

20204 

20204 

CHI 

4203 

-27703 

202 

250 

35 

20204 

20201 

cm 

4270 

-27107 

202 

234 

40 

20204 

1 

101 

c c,o 

‘,271 

-27143 

202 

250 

55 

20204 

10201 

MI 

4272 

-27155 

202 

250 

57' 

20204 

10201 

2 

am 

4273 

-2?'l35 

2241 

20225 

CHI 

4V_0 

202 

234 

40 

20204 

1 

102 

GVJ 

d'.Jo 

'-vv> 

202 

250 

50 

20204 

10201 

CHI 

4:.50 

-25201 

202 

250 

vK, 

20204 

2C2G4 

cn: 

*;:zs 

-25003 

202 

250 

33 

20204 

20202 

am 

*:cz5 

-24502 

202  • 

250 

56 

20204 

20204 

am 

crr  -•[ 
* v . J 

-70;  *914 

202 

254 

40 

2C204 

l 

101 

avJ 

*:To 

-23414 

202 

250 

56 

20204 

10201 

am 

47  CO 

-25415 

202 

250 

57 

20204 

1C201 

3 

am 

*.'701 

-2541 3 

5141 

2241 

20225 

am 

4 /// 

-22547 

202 

254 

40 

20204 

1 

102 

avo 

-22522 

202 

250 

53 

20204 

1C.2C1 

am 

log  r 

-22504 

202 

250 

36 

20204 

5100 

cm 

357 1 

-21521 

202 

250 

VC 

2020*1 

2200 

am 

oVV  ) 

-21152 

202 

259 

40 

202C4 

1 

101 

avo 

2110 

-20959 

202 

250 

56 

20204 

202 04 

am 

57C5 

-20302 

202 

250 

36 

20204 

1 02 01 

am 

5:07 

— ,cui/00 

202 

250 

57 

20204 

10201 

3 

am 

52CO 

-20300 

5141 

2241 

20225 

am 

3 

-20071 

202 

234 

40 

20204 

1 

102 

cm 

3273 

-20033 

202 

250 

50 

2020*? 

1S201 

am 

5274 

-19744 

202 

250 

56 

20204 

20204 

MI 

NOTES:  1.  TYPE  is  CMI  for  control  message  input  and  CMO  for  control  message 

output. 

2.  TIME  is  in  19.2  millisecond  units. 

3.  CHAIR  and  WHO  are  given  as  HOST’.D  and  EXTENSION  (HHHXX) . 

4.  The  send  list  in  SPEAK  TO  commands  (37)  is  given  on  the  following 
line  as  HOSTID  and  LINK-200  (HHHLL) . 

5.  Function  codes  in  chairman  user  commands  (39  and  40)are  given  as 
user's  extension  and  function  code  (XXCC). 
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Table  2:  Sample  Trace  Record  — Data  Messages  Processed 


RECEIVE 

tide 

't  RACc  Rc.Cv5\D 

Hi'-.-ir  id  Aocwr 

rsrw  PONT 

RCVD 

NT 

TYPE- 

0 

r 

3202 

9 

-23695 

7 

-10259 

7307 

DO  I 

1 

3202 

0 

“25633 

7 

“10235 

7300 

Dm  I 

2 

“10239 

5202 

9 

-25631 

7 

“1C235 

7 b^.3 

D3 1 

3 

-1D223 

5202 

1 

-25629 

7 

-1G223 

730'? 

DO  I 

•i 

“10221 

3202 

5 

-25617 

7 

-10222 

7309 

DO  I 

5 

-10219 

3202 

10 

-25610 

7 

-10219 

7303 

DO  I 

f 

-10209 

3202 

G 

“25603 

7 

“10209 

7303 

DO  I 

7 

-10199 

3202 

6 

-25596 

7 

“19179 

7303 

DO  I 

t J 

-10192 

3102 

9 

“2555 9 

7 

“10193 

7307 

DM  I 

9 

-16000 

3022 

0 

“31165  “ 

19 

“16051 

19320 

DO  I 

:.o 

“16032 

3022 

1 

-31171 

19 

-16 03 7 

19320 

DO  I 

:i 

“16312 

3022 

0 

“31167 

19 

-16017 

19321 

DO  I 

\ • 

* 4* 

-16009 

3022 

7 

-31193 

19 

“16009 

19521 

DO  I 

< V 

“16292 

3022 

G 

“31129 

19 

-16797 

19321 

DO  I 

1*; 

-16/63 

3022 

9 

-31115 

19 

-16709 

19320 

DO  I 

ib 

-16220 

3022 

10 

-31101 

19 

-16770 

19320 

DO  I 

lv.> 

••16251 

3022 

5 

-31GG7 

19 

“16751 

19320 

DO  I 

17 

-16232 

3022 

5 

-31073 

19 

-16737 

19320 

DO  I 

10 

-16226 

3022 

G 

-31059 

19 

-16726 

19320 

DO  I 

19 

“16210 

3022 

7 

“3109b' 

19 

-16711 

19520 

DOT 

20 

“16201 

3022 

10 

“31031 

7 

-167C5 

19320 

DO  I 

21 

“101/7.3 

3202 

0 

“25332 

9 

-16609 

M / vJ  > 

DO! 

2Z 

“16591 

32C2 

0 

“23656 

7 

“16599 

7 DbO 

DO! 

23 

-16529 

3202 

0 

-23979 

7 

“16503 

7300 

DO! 

2 7 

-16522 

5202 

9 

-23957 

7 

“16579 

7300 

DO  I 

25 

-16569 

32C2 

9 

“23350 

7 

-16569 

73  SO 

DO  I 

/fl 

“16562 

3202 

9 

-23953 

7 

“16557 

7300 

rv*j  f 

i/Hl 

27 

-16559 

3202 

3 

“239*i"  6 

7 

-16559 

7331 

DO  I 

29 

“16332 

3202 

0 

-23939  - 

7 

“16337 

7333 

DO! 

29 

“165301 

3202 

l\ 

-23932 

7 

“16b*.  9 

7332 

DO! 

30 

-16533 

3202 

e 

“23925 

7 

-16536 

7302 

DO! 

c I 

-16325 

3202 

9 

-2391 G 

7 

“16525 

7302 

do: 

32 

-16520 

3202 

10 

“23911 

7 

-16523 

7302 

DO  I 

53 

“16511 

32C2 

9 

-2390/9 

7 

“16511 

7332 

DO  I 

59 

-16505 

3202 

10 

-230/77 

7 

“16515 

7301 

DO  I 

3o 

“16991 

3202 

3 

“23090 

7 

“1G991 

7302 

Dor 

_ j 

“169G9 

3202 

G 

“23033 

7 

-16993 

7302 

DO  I 

33 

-16903 

32C2 

9 

“23076 

7 

-16903 

7302 

DO  I 

-169/0 

3202 

10 

-23C59 

7 

-169 Cl 

7332 

DO! 

39 

“16920 

3202 

10 

“23052 

7 

-16972 

7502 

DO  I 

90 

“160053 

32C2 

10 

“23055 

7 

“16968 

7302 

DO  I 

91 

-16956 

3202 

10 

“23093 

7 

“16957 

7502 

DO  I 

£? 
• /- 

-16995 

3202 

7 

-23091 

7 

“16995 

7333 

DO  I 

93 

“16992 

3202 

10 

“25G39 

7 

“16593 

730 2 

DO  I 

99 

-16935 

3202 

10 

-23027 

7 

-16937 

7302 

DO! 

•5 

-16921 

3202 

9 

“23320 

7 

-16921 

7303 

CO  I 

93 

“16919 

3202 

7 

“23013 

7 

-16927 

7502 

DM  I 

93 

“16919 

3202 

11 

-23C06 

7 

-16919 

7392 

DO  I 

•".  J 

“16902 

3202 

10 

-23797 

7 

“16912 

7332 

DO  I 

99 

“16900 

3202 

10 

-23792 

7 

-16905 

7332 

DO  I 

50 

“16393 

3201 

10 

“237C5 

7 

-16395 

7382 

DO  I 

NOTES:  1. 

TIME  is 

the  time 

the  message 

was 

selected 

for  processing 

2. 

A0CNT  is 

the  number  of  frames  of 

data  ready  for  D/A  outpi 

3. 

RCVD  is 

the  time 

the  message 

was 

received 

from  the  net. 
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Appendix  A:  NVCP  Control  Messages 

f Only  conferencing  protocol  control  messages  are  included  here.  A comp- 

lete listing  of  these  messages  appears  in  [3],  Reference  [2]  describes  the 
messages  of  the  network  voice  protocol. 

The  following  terms  are  used: 


<CHAIR>  The  8-bit  H0ST1D  and  8-bit  EXTENSION  of  the  chairman.  This 

* appears  as  the  second  word  in  all  NVCP  control  messages. 

Shown  in  trace  listings  as  3-digit  HOSTID  and  ^-digit  EXTENSION. 


<USER> 

<PARTICIPANX> 

<SPEAK£R> 


The  HOSTID  and  EXTENSION  of  an  individual  participant  or  poten- 
tial participant  in  the  conference.  Shown  in  trace  listings  as 
3-digit  HOSTID  and  2-digit  EXTENSION. 


<JUNCTION^>  The  8-bit  EXTENSION  of  the  participant  and  an  8-bit  function 

code.  Shown  in  trace  listings  as  2-digit  EXTENSION  and  2-digit 
function  code. 

MfflERE>  The  HOSTID  and  LINK  of  an  LCC  data  receiver.  Shown  in  trace 

listings  as  3-digit  EXTENSION  and  2 low-order  digits  of  LINK. 
Third  digit  of  link  is  2. 

1.  "Request  to  Join" 


33,  CHAIR>,  <USER>,  K 

This  message  is  sent  by  the  LCC  to  the  chair  on  link  255  to  establish  a 
connection.  It  initiates  the  standard  NP  vocoder  negotiation  with  the 
calling  message  replaced  by  this  one.  K is  the  Link  on  which  the  LCC 
expects  control  messages.  K+l  is  the  link  for  data  messages,  ''nee  a 
connection  is  established,  this  message  is  sent  on  the  CHAIR's  control 
link  to  introduce  additional  participants. 


2.  "Add  your  Participant" 

34,  <CHAIR>,  PARTICIPANT 

Sent  by  CHAIR  to  LCC  to  accept  a participant. 

3.  "Remove  a Participant" 

35,  s.CHAIR>,  PARTICIPANT 


Sent  by  CHAIR  to  LCC  to  reject  a participant  or  acknowledge  that  he  has 
left  the  conference. 
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Sent  by  CHAIR  to  terminate  a particular  speaker  and  cause  the  LCC  to 
stop  sending  data  messages. 

7.  "Control  functions  for  Users" 

39,  <CHAIR_x,  N,  <JUNCTION  <JUNCTIONN> 

Sent  by  CHAIR  to  provide  control  functions  for  sp' cific  participants. 
Function  code  1 means  "Wrap  Up"  when  sent  to  the  speaker. 

8.  "Control  functions  for  Chairman" 

AO,  <CHAIR>,  N,  UNCTION  , V , <FUNCTION  > 

Sent  by  LCC  to  provide  control  functions  from  particular  participants  to 
the  chairman.  Function  code  1 is  a "Request  to  Speak"  function.  Function 
code  2 is  a "Speaker  Done"  function. 

9.  "Lost  a Participant" 

Al,  CCHAIR^i  -^PARTICIPANT 

Sent  by  an  LCC  to  notify  CHAIR  that  a participant  has  left  the  conference. 
The  CHAIR  responds  with  a 35  message. 


i - 

i 


2A 


2.  Cohen,  D.,  "Specifications  for  the  Network  Voice  Protocol  (NVP),"  NSC 

Note  68,  January  1976. 

3.  Cohen,  D. , "The  Network  Voice  Conference  Protocol  (NVCP)",  USC/Information 

Sciences  Institute,  November  1975. 
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*ihis  report  covers  the  activities  of  CHI  in .development  of  a network  voice  con- 
ferencing system  using  linear  predictive  coding  for  speech  data  compression  from 
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sion  of  an  existing  network  speech  compression  system  incorporating  control 
messages  for  speaker  selection  and  data  routing,  together  with  transmitting  and 
receiving  programs  which  respond  to  them.  The  current  implementation  of  this  1 
system  at  CU1  is  described.  The  system  monitoring  and  recording  facilities  imp-| 
lemented  are  discussed  with  examples  nf  Hm-i  »•  usc  f°r  analysis  of  system 
' _ . performance. 
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